A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
This application relates to the following co-pending applications, assigned to the same assignee hereof, which is incorporated herein by reference.
{1114} U.S. Ser. No. 09/676,286 entitled A COMPUTER-IMPLEMENTED METHOD FOR REPRESENTING JAVA USING UML COMPLIANT TOOLS;
{1115} U.S. Ser. No. 09/676,289 entitled A METHOD FOR SYNCHRONIZING JAVA WITH UML IN A VERSION CONFIGURATION MANAGEMENT SYSTEM; and,
{1119} U.S. Ser. No. 09/676,288 entitled A COMPUTER-IMPLEMENTED METHOD FOR GENERATING JAVA FROM A UML REPRESENTATION.
The present invention generally relates to computer-implemented processes and in particular to a process that synchronizes UML with JAVA in a version configuration management system.
A problem arises when using the method disclosed in the above-referenced co-pending patent application, which allows for the translation and generation of JAVA files into UML, and vice-versa. JAVA is a programming language, which was developed by Sun Microsystems, Inc. of Mountain View, Calif.
When JAVA files are translated to form XMI representations of UML at the class, package, and project levels, the user must deal with multiple file representations of the same object. For instance, a project containing five packages, where each package contains five class files adds to a total of thirty-one files (one project, five package, and twenty-five class files).
As JAVA files generate UML representations, and UML Models are transformed into JAVA files, there is a need to synchronize all of the associations between the files.
Traceability for application assembly is another problem to be solved. Application assembly allows various projects to share assets with one another. Hence, the ability to track down how projects share files with one another is critical.
The product addresses this need by using versioning. First, the product implements the Unisys Version and Configuration System (VCS) to version both JAVA code and XMI.
Next, the product implements a JAVA parser/generator and XMI parser/generator to provide forward and reverse engineering between JAVA code and XMI.
The product then associates JAVA code and XMI at the class, package, and project levels using VCS. A soft-link association is created between each JAVA and UML file pair.
In order to support tracing for application assembly, link associations are also created between various projects. These links are used for versioning and allow for traceability between the projects.
A feature of the present invention resides in the ability to perform round trip engineering between UML and JAVA.
Another feature of the present invention resides in the ability to synchronize JAVA and UML with finer granularity, by creating links between JAVA files and UML objects at the class, package, and project levels.
Still another feature of the present invention resides in traceability between projects.
An advantage of the present invention is the use of versioning to provide traceability.
These and other objects, which will become apparent as the invention is described in detail below, are provided by a computer implemented-method for synchronizing JAVA in a UML in a computer system executing a repository program. The method comprises the steps of determining if a previous revision of UML representation exist, and if not; creating a new revision thereof. Next, the new revision is put in a xe2x80x9ccreatedxe2x80x9d state and stored in a new UML representation in the UML revision. The UML revision is then put in a xe2x80x9creadyxe2x80x9d state. After this, a determination is made as to whether or not there are more UML classes/interfaces; and if there are, a JAVA revision ID is extracted from the UML class/interface. Another determination is made as to whether or not a JAVA revision exist, and if not; a new revision of JAVA source is created and put into a xe2x80x9ccreatedxe2x80x9d state. JAVA source is then generated from a UML representation and stored in the new revision and put into a xe2x80x9creadyxe2x80x9d state. All of the steps are repeated until there are no more UML classes/interfaces.